I will never give up, please review:)

Here are some issues I found:

• Currently this banner "you don't have permission" is applying to all rooms when the user is muted in a room.
• The error message not handled when the user sends out message when he is muted in a room after he joins the room

/

/
2. User Ban is timeline event: "m.room.power_levels" https://matrix-org.github.io/matrix-rust-sdk/matrix_sdk/ruma/events/enum.AnyStateEventContent.html#variant.RoomPowerLevels

My advice is to always check the behavior of the element.io for the correct api to use. Use two accounts, both in the same room. One mutes the other, you should already see the message text input bar hidden for the muted user. Hence there is no "can_user_send_message" checks in between.

My advice is to always check the behavior of the element.io for the correct api to use. Use two accounts, both in the same room. One mutes the other, you should already see the message text input bar hidden for the muted user. Hence there is no "can_user_send_message" checks in between.

Done.

@CodiumAI-Agent /review

PR Reviewer Guide 🔍

(Review updated until commit b700faa)

Here are some key observations to aid the review process:

My advice is to always check the behavior of the element.io for the correct api to use. Use two accounts, both in the same room. One mutes the other, you should already see the message text input bar hidden for the muted user. Hence there is no "can_user_send_message" checks in between.

Done.

Nope, you need to also inspect the network using browser dev tool and understand matrix api.

1. Handle RoomPowerLevel change https://docs.rs/matrix-sdk-ui/0.7.0/matrix_sdk_ui/timeline/enum.AnyOtherFullStateEventContent.html here in sliding_sync.rs line 1632.
2. Remove the check_user_permission function from the process_timeline_updates function
3. Only call can_send_message async function when entering the room. Nothing to do with timeline.

Persistent review updated to latest commit b700faa

@Demolemon11

Core requirements:

• ✅ Correctly implemented the visibility logic for the message input control
• ✅ Implemented permission checks and controlled the UI based on the results
• ✅ Implemented clear prompts for when messages cannot be sent

Implementation details:

• ✅ Used Room:can_user_send_message() to check permissions
• ✅ Displays a prompt instead of the input box when permissions are insufficient

Suggestions for improvement:

• ❌ Lacks a subscription mechanism for permission changes
• ❌ Lacks unsubscribe logic when leaving the room
• ❌ Only checks permissions once when opening the room, without periodic checks

Code improvement suggestions:

• Using i64 type for permission values is not intuitive. Please refactor the permission status to a clearer enum type.
• Missing documentation comments for permission status, please add them.
• Permission check logic is scattered in multiple places, please centralize the management of permission-related logic.
• Lacks an event listening mechanism for permission changes.
• Please add complete error handling.
• Need to set a reasonable time interval for permission checks.
• Need to optimize the timing of state updates.

Suggestions for improvement:

• ❌ Lacks a subscription mechanism for permission changes

this can be done in a future PR, too, if you want to keep this one simple/manageable. Multiple smaller PRs are preferred over one big PR.

• ❌ Lacks unsubscribe logic when leaving the room

Same comment as above.

• ❌ Only checks permissions once when opening the room, without periodic checks

I think this is the same thing as the first point. As I mentioned in one of my earlier comments, a subscription mechanism that asynchronously awaits updates to a user's power levels is much better than periodically checking it from the main UI thread, since updates to user power levels are very infrequent.

The Permission banner based subscription of the power level change works.

1. For the Power change message, add "from Default to Custom (-1)" Following Element.io

/

result:
Screencast from 2024-12-19 10-45-35.webm

bug:
Screencast from 2024-12-19 10-52-25.webm
Thanks for review.

It seems there is a bug: input_bar reshow after resizing to mobile layout.
I guess the reason is lack of permission inspection.
Should I fix it in this pr?

result: Screencast from 2024-12-19 10-45-35.webm

Very nice, looks great!

bug: Screencast from 2024-12-19 10-52-25.webm Thanks for review.

It seems there is a bug: input_bar reshow after resizing to mobile layout. I guess the reason is lack of permission inspection. Should I fix it in this pr?

Yeah that's the same issue as the issue you had with the verification badge not persisting across mobile <--> desktop UI changes. The state of the widget gets reset.

You can fix it in a future PR or now, your choice.

I haved merged it when you read this comment.

I just found another bug, the hints should be collapsed just like the message input bar:

I'll fix the two bugs I mentioned in the future pr.

Thanks very much!

Thanks, yeah those two should be easy enough to fix. The overflow of the permission message text can be fixed by setting its width: Fill and wrap: Word.